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Abstract 


This  report  documents  the  work  done  to  prototype  a  marine  mammal  detection  system. 
The  resulting  system  will  support  environmental  mitigation  measures  prior  to,  and 
during,  active  sonar  trials  and  exercises.  A  working  application  was  delivered  at  the 
end  of  the  call-up  that  allows  a  user  to  configure  and  run  detection  processing,  with 
live  updates  provided,  or  to  post-analyze  data  from  a  previous  detection  run.  Once 
selected,  an  image  of  the  detection  and  the  corresponding  detection  log  entries  are 
presented  to  the  user.  The  user  can  also  listen  to  the  detection  and  bring  up  a  time 
series  plot  of  the  raw  data.  A  cursor  can  be  used  to  measure  times  and  frequencies  on 
the  detection  image.  This  system  was  used  to  process  30  minutes  of  Right  whale  data 
collected  using  sonobuoys.  Deshamais  collected  this  data  set  in  the  Bay  of  Fundy 
during  the  summer  of  1999.  This  data  set  included  dead  channels,  considerable  radio 
frequency  (RF)  interference  and  a  digital  data  channel.  Fifty-seven  valid  detections 
were  made  while  the  sixteen  false  alarms  that  did  occur  were  easily  classified  and 
rejected.  No  analysis  of  missed  contact  was  made.  After  a  quick  look  at  the  data,  it 
took  an  acoustic  operator  less  than  a  second  to  distinguish  a  valid  call  from  a  false 
alarm  as  he  scrolled  through  the  results.  Aural  listening  helped  to  quickly  distinguish 
valid  vs.  invalid  contacts.  There  is  still  considerable  room  for  improvement  in  the 
automatic  classification  and  graphical  user  interface  (GUI)  layout  but,  as  a  prototype, 
it  demonstrates  that  good  detections  can  be  made  and  classified  using  a  system  such  as 
this.  The  processing  stream  is  based  primarily  on  existing  signal  processing  library 
(SPLIB)  and  sonar  library  (SONLIB)  modules  developed  under  previous  call-ups.  The 
GUI  was  based  on  existing  QT-based  widgets  developed  under  the  Omni  Passive 
Display  (OPD)  call-up. 


Resume 


Le  present  rapport  fait  etat  des  travaux  effectues  sur  un  systeme  prototype  de  detection 
de  mammiferes  marins.  La  version  finale  du  systeme  viendra  appuyer  les  mesures  de 
protection  environnementale  avant  et  pendant  les  essais  et  exercices  faisant  appel  au 
sonar  actif.  A  la  fin  de  la  commande  directe,  F entrepreneur  a  livre  une  application 
operationnelle  qui  permet  a  l’utilisateur  de  configurer  et  d’executer  le  traitement  des 
donnees  de  detection,  avec  des  mises  a  jour  en  temps  reel,  ou  d’effectuer  une  analyse 
posterieure  des  donnees  d’un  essai  de  detection  anterieur.  Une  fois  selectionnee,  une 
image  de  la  detection  et  les  entrees  correspondantes  dans  le  journal  de  detection  sont 
presentees  a  l’utilisateur.  L’utilisateur  peut  egalement  ecouter  le  signal  sonore  de  la 
detection  et  appeler  a  l’ecran  un  graphique  chronologique  des  donnees  brutes.  Un 
curseur  peut  etre  utilise  pour  mesurer  le  temps  et  les  frequences  de  F image  de 
detection.  Ce  systeme  a  ete  utilise  pour  traiter  30  minutes  de  donnees  de  detection  de 
baleines  noires  collectees  au  moyen  de  bouees  acoustiques.  Desharnais  a  collecte  cet 
ensemble  de  donnees  dans  la  baie  de  Fundy  au  cours  de  Fete  1999.  Get  ensemble  de 
donnees  comprenait  des  canaux  inactifs,  du  brouillage  radioffequence  (RF) 
considerable  et  un  canal  de  donnees  numeriques.  Cinquante-sept  detections  valides  ont 
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ete  effectuees,  tandis  que  les  seize  fausses  alertes  qui  se  sont  produites  ont  ete  faciles  a 
classifier  et  a  rejeter.  Aucune  analyse  de  contacts  manques  n’a  ete  effectuee.  Apres  un 
survol  rapide  des  donnees,  un  operateur  de  detecteurs  acoustiques  a  mis  moins  d’une 
seconde  a  distinguer  entre  un  contact  valide  et  une  fausse  alerte  pendant  qu’il  faisait 
defiler  les  resultats.  L’oui'e  a  aide  a  distinguer  rapidement  entre  les  contacts  valides  et 
non  valides.  II  y  a  encore  beaucoup  de  chemin  a  faire  a  l’egard  de  la  classification 
automatique  et  de  la  disposition  de  l’interface  graphique  (GUI),  mais  le  prototype  a 
montre  que  de  bonnes  detections  peuvent  etre  effectuees  et  classifies  au  moyen  d’un 
systeme  de  ce  genre.  Le  flux  de  traitement  est  essentiellement  fonde  sur  les  modules 
existants  de  bibliotheque  de  traitement  de  signaux  (SPLIB)  et  de  bibliotheque  sonar 
(SONLIB)  developpes  dans  le  cadre  de  commandes  directes  anterieures.  L’interface 
GUI  etait  basee  sur  des  objets  fenetres  axes  sur  QuickTime  developpes  dans  le  cadre 
de  la  commande  directe  visant  l’affichage  Omni  passif  (OPD). 


DRDC  Atlantic  CR  2005-271 


Executive  summary 


Background 

DRDC  Atlantic  has  an  ongoing  research  program  that  requires  the  transmission  of  acoustic 
energy  in  an  undersea  environment.  Though  the  transmissions  are  generally  at  a  relatively 
low  level,  every  effort  must  be  made  to  mitigate  the  potential  for  impact  on  marine  life. 

Recent  increased  awareness  regarding  the  potential  for  adverse  impact  on  marine  fauna  from 
anthropogenic  noise  has  resulted  in  further  research  being  undertaken  to  study  the  impact 
mechanisms  and  possible  mitigation  measures.  Future  impact  mitigation  measures  may 
include  the  development  of  detection  and  classification  capabilities  for  marine  mammal 
vocalizations.  The  ocean  environment  tends  to  be  noisy,  so  that  the  detection  of  noise  itself 
is  inadequate  for  alerting  researchers  of  the  presence  of  marine  mammals.  The  “noise”  must 
be  classified  as  to  its  origin,  e.g.  has  it  been  generated  by  a  marine  mammal.  The  objective 
of  this  contract  was  to  develop  a  prototype  acoustic  auto-alert  system  for  use  on  DRDC 
Atlantic  sea  trials. 

Results 

A  working  application  was  delivered  at  the  end  of  the  contract  that  allows  a  user  to 
configure  and  run  detection  processing,  with  live  updates  provided,  or  to  post-analyze  data 
from  a  previous  detection  run.  Once  selected,  an  image  of  the  detection  and  the 
corresponding  detection  log  entries  are  presented  to  the  user.  The  user  can  also  listen  to  the 
detection  and  bring  up  a  time  series  plot  of  the  raw  data.  A  cursor  can  be  used  to  measure 
times  and  frequencies  on  the  detection  image.  This  system  was  used  to  successfully  process 
30  minutes  of  sonobuoys  data  containing  Northern  Right  whale  vocalizations. 

Significance 

There  is  still  considerable  room  for  improvement  in  the  automatic  classification  and 
graphical  user  interface  (GUI)  layout  but,  as  a  prototype,  it  demonstrates  that  detections  can 
be  made  and  classified  using  a  system  such  as  this. 

Future  Plans 

The  initial  testing  of  the  system  has  been  very  positive.  However,  more  testing  is  required 
with  “noisy”  data.  Beyond  more  testing,  the  addition  of  classifier  algorithms  and  analogue 
“click”  detectors  are  the  obvious  next  steps. 
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Sommaire 


Contexte 

RDDC  Atlantique  nine  un  programme  de  recherche  permanent  qui  exige  la  transmission 
d’energie  acoustique  dans  un  environnement  sous-marin.  Bien  que  les  transmissions  soient 
generalement  d’un  niveau  relativement  faible,  il  faut  tout  faire  pour  attenuer  l’incidence 
potentielle  sur  la  biosphere  marine. 

La  conscience  accrue  depuis  peu  quant  a  l’effet  nuisible  potentiel  du  bruit  anthropique  sur  la 
faune  marine  a  donne  lieu  a  des  recherches  approfondies  sur  les  mecanismes  en  cause  et  les 
mesures  d’attenuation  possibles.  Les  mesures  futures  d’attenuation  de  l’incidence  peuvent 
comprendre  le  developpement  des  capacites  de  detection  et  de  classification  des 
vocalisations  des  mammiferes  marins.  L’ environnement  oceanique  tend  a  etre  bruyant,  de 
sorte  que  la  detection  du  bruit  en  soi  ne  suffit  pas  pour  alerter  les  chercheurs  a  la  presence  de 
mammiferes  marins.  Le  «  bruit »  doit  etre  classifie  selon  son  origine,  c.-a-d.  qu’il  faut 
determiner  s’il  a  ete  produit  par  un  mammifere  marin.  Le  contrat  en  cause  avait  pour  objectif 
de  developper  un  systeme  prototype  d’alerte  acoustique  automatique  pour  utilisation  pendant 
les  essais  en  mer  de  RDDC  Atlantique. 

Resultats 

A  la  fin  du  contrat,  f  entrepreneur  a  livre  une  application  operationnelle  qui  permet  a 
1’utilisateur  de  configurer  et  d’executer  le  traitement  des  donnees  de  detection,  avec  des 
mises  a  jour  en  temps  reel,  ou  d’effectuer  une  analyse  posterieure  des  donnees  d’un  essai  de 
detection  anterieur.  Une  fois  selectionnee,  une  image  de  la  detection  et  les  entrees 
correspondantes  dans  le  journal  de  detection  sont  presentees  a  1’utilisateur.  L’utilisateur  peut 
egalement  ecouter  le  signal  sonore  de  la  detection  et  appeler  a  l’ecran  un  graphique 
chronologique  des  donnees  brutes.  Un  curseur  peut  etre  utilise  pour  mesurer  le  temps  et  les 
frequences  de  l’image  de  detection.  Ce  systeme  a  ete  utilise  avec  succes  pour  traiter 
30  minutes  de  donnees  de  bouees  acoustiques  contenant  des  vocalisations  de  baleines  noires 
de  l’Atlantique  Nord. 


Portee 


II  y  a  encore  beaucoup  de  chemin  a  faire  a  l’egard  de  la  classification  automatique  et  de  la 
disposition  de  1’ interface  graphique  (GUI),  mais  le  prototype  a  montre  que  des  detections 
peuvent  etre  effectuees  et  classifies  au  moyen  d’un  systeme  de  ce  genre. 

Recherches  futures 

Les  essais  initiaux  du  systeme  sont  tres  encourageants.  Toutefois,  il  faut  des  essais 
supplementaires  au  moyen  de  donnees  «  bruyants  ».  En  outre,  l’ajout  d’algorithmes  de 
classification  et  la  mise  en  oeuvre  de  detecteurs  analogiques  de  «  clics  »  sont  les  etapes 
logiques  suivantes. 


IV 
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1.  Introduction 


This  final  report  outlines  the  work  done  under  Noise  Monitoring  Software  Regional  Individual 
Standing  Offer  (RISO)  No.  W7707-032293/00 1/HAL,  Call-up  Requisition  No.  W7707-04-2801. 
This  work  was  performed  for  Defence  R&D  Canada  (DRDC)  -  Atlantic  under  the  direction  of  the 
Scientific  Authority  (SA),  Jim  Theriault,  from  approximately  February  2005  to  September  2005. 
Some  aspects  of  the  work  in  Call-up  Requisition  No.  W7707-04-2767  under  the  direction  of  the 
SA,  Prakash  Deonarine,  is  also  discussed,  with  that  work  used  as  a  basis  for  this  call-up. 


1.1  Overview 

DRDC  Atlantic  is  required  to  produce  a  prototype  system  that  will  provide  detection  and 
classification  of  whales  and  other  marine  mammals.  The  resulting  system  will  be  used  to  support 
environmental  mitigation  measures  prior  to,  and  during,  active  sonar  trials  and  exercises.  This  call¬ 
up  was  generated  to  develop  the  prototype  that  would  meet  this  requirement. 

The  objective  of  the  previous  call-up  was  to  provide  enhancements  to  the  existing  Sentinel  module 
in  the  signal  processing  packages  (SPPACS)  suite  and  the  enhancement  necessary  to  support 
assessment,  refinement  and  rationalization  of  the  detection  algorithm  for  marine  mammals. 
Additionally,  this  call-up  was  concerned  with  developing  core  signal  processing  software  that 
could  be  later  integrated  into  a  whale  detection  and  classification  system. 

The  objective  of  the  second  call-up  was  to  provide  feature  extraction  processing  and  GUI  for  the 
operator.  The  feature  extraction  capability  could  include  image  de-noise,  image  segmentation  and 
feature  extraction.  The  GUI  would  display  the  gram  image  output,  detection  details  (i.e.,  channel, 
band,  etc.)  and  provide  data  assessment  to  support  manual  classification. 

Several  papers  have  been  produced  detailing  whale  detection  and  classification  algorithms  and  the 
performance  of  those  algorithms  given  real  data.  Analysis  of  those  algorithms  against  existing 
SONLIB/SPLIB  modules  revealed  that  much  of  the  software  required  to  develop  a  whale 
detection  and  classification  system  already  existed.  The  two  modules  of  interest  are  the  Sentinel 
detector  and  the  passive  processing  module.  Under  the  direction  of  the  SA,  MacDonald  Dettwiler 
and  Associates  Ltd.  (MDA)  used  the  Sentinel  and  omni  passive  processing  modules  to  develop  a 
generic  transient  detection  and  classification  framework  from  which  specific  whale  detection  and 
classification  algorithms  could  be  implemented. 

A  working  application  was  delivered  at  the  end  of  the  call-up.  It  allows  a  user  to  configure  and  run 
detection  processing,  with  live  updates  provided  in  the  window,  or  to  post-analyze  data  from  a 
previous  detection  run.  Once  selected,  an  image  of  the  detection  and  the  corresponding  detection 
log  entries  are  presented  to  the  user.  The  user  can  also  listen  to  the  detection  and  bring  up  a  time 
series  plot  of  the  raw  data.  A  cursor  can  be  used  to  measure  times  and  frequencies  on  the  detection 
image. 

The  new  application  was  used  to  process  30  minutes  by  49  channels  of  Right  whale  data  collected 
using  sonobuoys.  This  data  was  collected  by  Francine  Desharnais  in  the  Bay  of  Fundy  during  the 
summer  of  1999.  This  data  included  dead  channels,  considerable  RF  interference  and  a  digital  data 
channel.  Fifty-seven  valid  detections  were  made  while  the  sixteen  false  alarms  that  did  occur  were 
easily  classified  and  rejected.  No  analysis  of  missed  contact  was  conducted.  After  a  quick  look  at 
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the  data,  it  took  an  acoustic  operator,  Joe  Hood,  less  than  a  second  to  distinguish  a  valid  call  from 
a  false  alarm  as  he  scrolled  through  the  results.  Aural  listening  quickly  helped  to  distinguish  valid 
versus  invalid  contacts.  There  is  still  room  for  improvement  in  the  automatic  classification  and 
GUI  layout,  but  as  a  prototype  it  demonstrates  that  good  detections  can  be  made  and  classified 
using  a  system  such  as  this. 

In  reality  the  delivered  application  is  a  transient  detection  system  and  could  be  used  for  other 
purposes.  The  Acoustic  Data  Analysis  Center  (ADAC)  has  already  shown  an  interest  in  using  it 
for  detecting  and  viewing  submarine  transients. 

This  report  is  broken  into  five  main  sections.  The  remainder  of  this  section  provides  background 
on  the  software  used  during  the  call-up.  Section  2  provides  an  overview  of  the  call-up’s  software 
development  requirements  and  work  performed  to  meet  those  requirements.  Section  3  documents 
the  data  analysis,  results  and  recommendations.  Section  4  details  software  configuration 
management  processes  and  the  versions  used  for  this  call-up.  Section  5  provides  a  summary  of 
current  software  issues. 


1.2  Background 

The  data  processing  and  analysis  work  was  performed  using  two  software  suites:  Software  Tools 
for  Analysis  and  Research  (STAR)  and  SPPACS.  An  overview  of  the  two  software  suites  is 
provided  in  the  following  subsections. 

The  STAR  and  SPPACS  suites  are  configuration  controlled  using  the  concurrent  versioning 
system  (CVS).  Issue  and  enhancement  idea  tracking  is  affected  using  the  Bugzilla  issue  tracking 
software.  CVS  is  a  repository  that  allows  developers  to  check-in  revisions  to  software  and 
documentation  where  they  are  archived  in  a  common  database.  The  tool  allows  all  previous 
versions  of  the  software  to  be  maintained  and  aids  resolution  of  new  issues,  while  ensuring  that 
current  builds  of  the  software  are  readily  accessible  to  users  and  developers  alike.  Bugzilla  is  a 
web  accessible  database  that  offers  both  user  and  developer  input  to  issues,  priorities  and 
solutions.  It  provides  coherent  tracking  and  recording  of  an  issue  over  its  entire  lifecycle. 

STAR  and  SPPACS  components  are  documented  in  a  combination  of  formats,  each  with  their  own 
purpose.  Microsoft  Word  documents  are  maintained,  which  describe  functionality  and  algorithms 
of  components.  These  are  primarily  intended  for  the  end  user.  Enterprise  Architect  (EA)  files  are 
maintained,  which  document  software  design,  interaction  and  dependencies.  EA  design 
information  is  intended  primarily  for  developers.  Hypertext  Markup  Language  (HTML)  library 
documentation  is  being  developed  that  provides  automatic  extraction  of  the  routine’s  Application 
Program  Interface  (API),  purpose  and  description.  This  documentation  is  maintained  to  assist 
developers  in  familiarizing  themselves  with  the  existing  libraries  and  components,  and  is  intended 
to  support  and  encourage  software  reuse.  Some  users  may  also  wish  to  refer  to  this  information  for 
use  in  their  own  custom  applications.  SPPACS  also  provides  HTML  and  man  page  user 
documentation  for  each  module. 

The  most  current  status  of  the  SPPACS  and  STAR  suites  can  be  found  at  https://star.iotek.ns.ca. 
Users  are  also  encouraged  to  refer  to  the  electronic  documentation  provided  with  the  software 
distribution  for  up-to-date  information. 
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1.2.1  STAR 


The  STAR  suite  was  developed  to  support  general  research  and  analysis  objectives  at  DRDC 
Atlantic.  The  primary  objectives  of  the  STAR  suite  are: 

•  Provide  scientific  grade  analysis  tools  that  allow  for  efficient,  detailed  quantitative  and 
qualitative  analysis  of  a  data  set. 

•  Support  synergy  between  DRDC  groups  and  the  Department  of  National  Defence  (DND)  by 
providing  a  common  software  base  for  analysis.  This  synergy  encourages  inter-group 
communication  and  simplifies  user  training,  analysis  process  development,  documentation 
and  data  portability. 

•  Support  cost  and  analysis  efficiency  by  providing  software  reuse  and  common  tools  and  data 
formats.  Examples  of  efficiency  would  be  using  the  output  of  analysis  from  one  group  to  feed 
the  inputs  of  another,  or  using  common  software  components  to  lower  development  cost  of 
several  custom  analysis  tools. 

All  STAR  components  are  currently  implemented  using  Interactive  Data  Language  (IDL),  though 
the  design  is  not  restricted  to  IDL.  The  name  STAR  reflects  the  generic  nature  of  the  software. 
Applications  in  the  STAR  suite  are  built  using  a  combination  of  reusable  and  custom  components 
that  meet  the  requirements  of  each  application.  The  layered  design  and  common  components  allow 
for  rapid  and  logical  development  of  new  capabilities.  Though  currently  focused  on  sonar  data 
processing  and  analysis,  the  tools  are  capable  of  expanding  to  meet  other  analysis  and  research 
requirements. 

1.2.2  SPPACS 

SPPACS  is  a  group  of  software  programs  that  are  based  on  the  C  programming  language  and  is 
implemented  on  Linux-based  personal  computers  (PC).  Each  program  provides  a  specific 
processing  function  and  a  series  of  programs  can  be  chained  together  to  create  a  custom¬ 
processing  stream  using  the  command  line  or  scripts.  The  output  from  SPPACS  is  stored  in  DREA 
formatted  data  files.  SPPACS  has  slowly  evolved  to  its  present  day  state  due  to  the  efforts  of 
several  MDA  personnel  over  the  last  4  years. 

SPPACS  has  been  used  to  perform  a  number  of  mid-trial  and  post-trial  processing  functions,  such 
as  the  post-trial  study  of  multistatic  trial  data  and  the  mid-trial  analysis  of  the  Q265  sonobuoy  test 
trial.  SPPACS  only  performs  data  manipulation  and  does  not  provide  an  interface  to  examine  the 
results.  The  processed  data  output  is  often  imported  into  other  applications  that  enable  data  display 
and  are  used  to  perform  the  detailed  analysis  of  the  results.  One  example  of  such  an  application  is 
the  STAR  suite. 

The  SPPACS  software  suite  consists  of  two  types  of  software.  One  type  is  runtime  executables 
that  can  be  used  to  process  DRDC  Atlantic  data  files  in  a  number  of  ways,  including  data 
management  and  signal  processing.  Each  program  performs  a  specific  function  and  the  programs 
are  designed  so  that  they  can  be  used  in  conjunction  to  perform  more  complex  processing  tasks. 
The  software  has  proven  to  be  very  useful  in  simplifying  data  management  and  sonar  processing 
tasks  by  providing  a  set  of  tools  from  which  to  build  the  necessary  processing  streams.  These 
streams  can  be  run  from  the  command  line  or  assembled  into  scripts  to  perform  batch-processing 
tasks  allowing  for  large  amounts  of  data  to  be  automatically  processed.  The  second  form  of  the 
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software  is  a  group  of  library  functions  that  can  be  used  by  other  programs  to  efficiently  perform 
standard  tasks.  These  library  functions  are  extensively  used  by  the  runtime  software,  but  are  also 
used  for  other  applications.  There  are  now  three  types  of  libraries.  The  first  are  utility  routines  for 
performing  tasks,  such  as  header  manipulation  and  command  line  parsing.  The  second  are  signal 
processing  modules  termed  SPL1B.  These  are  low-level  modules,  each  performing  a  low  level 
signal-processing  task.  A  new  SPPACS  module  typically  consists  of  one  or  more  SPL1B  modules 
linked  together  with  an  SPPACS  user  interface.  The  final  library  type  is  a  sonar  processing 
module  termed  SONLIB.  These  are  more  complex  modules  that  combine  several  SPL1B  modules 
to  create  a  complex  sonar  module,  such  as  passive  processing.  Separating  the  SPL1B  and  SONLIB 
modules  from  SPPACS  generated  more  generically  reusable  software.  SPL1B  and  SONLIB  are 
independent  of  the  data  header  format,  timestamping  method,  etc.  and  are  suitable  for  integration 
in  real-time  processing  systems. 

SPPACS  is  also  supported  by  a  set  of  signal  processing  libraries  known  at  the  Fastest  Fourier 
Transform  in  the  West  (FFTW).  These  free,  open-source  libraries  provide  optimized  signal 
processing  functions  helping  to  ensure  that  the  SPPACS  software  runs  as  efficiently  as  possible, 
while  providing  a  significant  reduction  in  coding  effort. 


4 


DRDC  Atlantic  CR  2005-271 


2.  Work  Overview 


This  section  presents  an  overview  of  the  tasked  and  completed  work.  The  development 
requirements  for  this  call-up  are  listed  in  Table  1  and  Table  2,  while  the  remainder  of  this  section 
indicates  how  each  requirement  was  met.  The  work  completed  under  this  call-up  was  included  in 
STAR  Release  4.8.0. 

This  section  is  not  meant  to  provide  all  technical  details.  A  detailed  description  of  the  algorithms 
and  technical  aspects  related  to  the  work  performed  under  this  contract  can  be  found  in  HTML 
documentation,  included  with  the  source  code.  It  will  be  found  in  the  acoustics  documentation 
directory,  which  is  generally  /usr/local/atools/acoustics/doc. 

Several  accomplishments  described  in  this  contract  rely  on  work  conducted  under  other  contracts. 
By  sharing  a  common  code  base,  several  contracts  were  able  to  reduce  the  amount  of  effort 
required  to  meet  their  individual  requirements  and  realize  more  overall  benefit  with  the  available 
funds. 

As  this  contract  was  restricted  by  a  limitation  of  expenditure  and  the  contract  objectives  were 
ambitious,  not  all  requirements  were  completely  implemented,  though  substantial  progress  was 
made.  MDA  worked  with  the  SA  to  ensure  that  the  call-up  deliverables  were  satisfactory  allowing 
trade-offs  to  be  made,  as  required.  The  following  requirements  were  not,  or  only  partially 
addressed: 


•  Transient  Feature  Extraction  -  This  section  of  processing  stream  was  not  implemented, 
though  a  binary  quantized  gram  was  presented  to  the  operator.  A  cursor  could  then  be  used 
to  perform  manual  feature  analysis.  An  aural  listening  capability  was  also  added  to  the 
GUI. 

•  Event  Analysis  -  As  feature  extraction  wasn’t  performed  no  detailed  event  information 
was  available.  Instead,  a  list  of  the  detection  log  entries  was  provided  in  the  GUI. 


Table  1.  Contract  Requirements  for  Whale  Detection  and  Classification  Aids  (Call-up  1) 

REQUIREMENT  TITLE 

ASSOCIATED  REQUIREMENTS 

Data  Buffering  and  Recording 

•  The  contractor  shall  implement  a  circular  buffer  module  that 
maintains  a  buffer  of  the  most  recent  N  records  of  data.  N  is  defined 
on  initialization.  If  a  detection  is  made  the  most  recent  N  records  plus 
a  user  defined  number  of  post-detection  records  shall  be  copied  to  a 
single  output  record  of  the  output  buffer  for  the  detecting  channel. 

•  The  contractor  shall  implement  a  wave  file  writer  module  that 
accepts  all  data  in  one  input  buffer  record  and  writes  it  to  a  single 
channel  wave  file  with  an  SA  defined  file-naming  scheme. 

Detection 

•  The  contractor  shall  generate  a  SONLIB  module  that  integrates  the 
modules  shown  in  Figure  1  and  exposes  the  SA  defined  parameters 
to  the  user. 
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Table  1.  Contract  Requirements  for  Whale  Detection  and  Classification  Aids  (Call-up  1) 

REQUIREMENT  TITLE 

ASSOCIATED  REQUIREMENTS 

Transient  Pre-processing 

•  The  contractor  shall  develop  a  time-frequency  normalizer  module  for 
SPLIB  under  SA  direction. 

•  The  contractor  shall  implement  a  binary  quantizer  module. 

•  The  contractor  shall  implement  a  module  that  convolves  an  SA 
defined  kernel  over  the  acoustic  ‘image’  produced  by  the  binary 
quantizer. 

Transient  Feature  Extraction 

•  The  contractor  shall  integrate  the  image  segmentation  software 
provided  by  John  Fawcett  into  an  SPLIB  module. 

•  The  contractor  shall  implement  an  SPLIB  module  that  finds  each 
segment  in  the  image  and  outputs  a  list  of  features  for  that  segment 
including: 

> 

Start  and  End  Frequency 

> 

Sweep  Frequency 

> 

Min  and  Max  Frequency 

> 

Position  of  Min  and  Max  Frequency 

> 

Instantaneous  bandwidth 

> 

Duration 

> 

Area  Ratio 

> 

Porosity 

> 

Mean  Center 

SPPACS  Whale  Detection 

•  The  contractor  shall  integrate  the  detection  and  feature  extraction 
modules  into  an  SPPACS  application  using  SA  defined  parameter 
options  and  SA  defined  data  output  options.  This  module  will  be 
used  for  testing  and  analysis  of  the  modules  performance. 

Table  2.  Contract  Requirements  for  Marine  Mammal  DC  System  Integration  (Phase  2) 

REQUIREMENT  TITLE 

ASSOCIATED  REQUIREMENTS 

Module  Integration 

•  The  contractor  shall  integrate  the  detection  and  feature  extraction 
modules  into  an  SPPACS  application  that  accepts  data  using  the 
method  described  in  Task  2. 

•  The  application  shall: 

•  Accept  configuration  information  using  the  method  agreed 
upon  in  Task  2. 

•  Accept  raw  data  using  the  method  agreed  upon  in  Task  2. 

•  Output  detection  event  Wave,  Feature  and  Image  files  using 
the  formats  defined  during  Task  2. 
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Table  2.  Contract  Requirements  for  Marine  Mammal  DC  System  Integration  (Phase  2) 

REQUIREMENT  TITLE 

ASSOCIATED  REQUIREMENTS 

Event  Analysis 

•  The  contractor  shall  create  a  STAR  application  that  allows  users 
to  see  a  list  of  current  detection  events  in  a  designated  directory 
and  analyze  those  events. 

•  The  application  shall: 

•  Present  the  user  with  a  list  of  events. 

•  Allow  the  user  to  view  the  Feature  and  Image  data. 

•  If  feasible,  play  the  Wave  file.  If  not,  then  the  Wave  file  name 
should  be  presented  to  the  user  for  manual  selection. 

•  Allow  the  user  to  annotate  the  Feature  file  with  a  manual 
classification  and  notes. 

2.1  Development  Work 

The  following  work  was  completed  to  address  the  requirements  listed  in  Table  1  and  Table  2. 
Figure  1  shows  the  component  diagram  for  the  transient  detection  system.  The  system  consists  of 
a  processing  stream  created  from  new  and  existing  SPLIB/SONLIB  modules,  an  SPPACS 
command  line  utility  and  a  QT-based  GUI.  A  considerable  amount  of  reuse  was  realized  under  this 
call-up  (approximately  50-60%).  The  modules  shaded  in  green  were  created  in  the  call-ups.  The 
modules  shaded  in  blue  were  enhancements.  In  this  case,  many  of  the  enhancements  resulted  from 
the  creation  of  a  lightweight  C++  wrapper  for  an  existing  module  (see  section  2. 1.1.1).  The 
modules  shaded  in  yellow  were  written  under  previous  call-ups.  The  modules  shaded  red  were  not 
completed. 
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Figure  1.  Component  Diagram  -Transient  Processing  Stream 


2.1.1  Processing  Modules 

This  section  describes  the  processing  modules  that  were  created  to  address  the  call-up 
requirements. 

2. 1. 1. 1  SPLIB++/SONLIB++  C++  Signal  Processing  Layer 

A  C++  based  control  layer  was  utilized  to  support  the  processing  stream.  The  SONLIB++/ 
SPLIB++  framework  provides  a  flexible/feature  rich  C++  layer.  The  framework  can  be  used  to 
create  lightweight  wrappers  around  existing  SPLIB/SONLIB  (C  based)  processing  modules. 
Additionally,  complex  control  modules  can  be  created  and  used  to  monitor  and  manage  the 
processing  stream.  Development  of  this  layer  was  shared  with  the  Rapid  Deployable  Systems 
Technology  Demonstration  (RDS  TD)  project. 
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The  following  wrappers  were  created  from  existing  SPLIB  modules: 

•  splib_extract 

•  splibdatain 

•  splibdataout 

•  spliblinquans 

•  splib_wave_transient 

The  following  wrappers  were  created  from  existing  SONLIB  modules: 

•  sonlibtransientdetection 

•  sonliblinavgspectra 

•  sonlib_transient_preprocess 

The  following  modules  were  written  using  the  framework: 

•  pausebuffercontrol 

•  logmessagescontrol 

2. 1.1. 2  Triggered  Buffer 

A  triggered  buffer  SPLIB  module  was  created  to  provide  a  block  of  data  around  an  event.  It  does 
this  by  cycling  raw  data  through  a  circular  buffer.  The  buffer  is  sized  to  ensure  that  a  full  data 
block  is  available.  The  module  monitors  the  Sentinel  module  for  new  detections  that  trigger  the 
output.  When  a  new  detection  occurs  the  module  waits  for  the  defined  number  of  post-event 
records  to  fill  the  internal  buffer,  and  then  copies  the  contents  of  the  internal  buffer  to  its  output 
buffer.  Each  chunk  of  data  contains  a  number  of  records  before  and  after  the  detection,  based  on 
user  settings. 

The  module  was  implemented  to  support  the  data  buffering  and  recording  requirement. 

2. 1. 1. 3  Pause  Buffer  Control 

The  application  needed  the  ability  to  process  a  detection,  reconfigure  processing  and  then  process 
data  from  the  next  detection.  To  do  this,  an  SPLIB++  module  (see  section  2. 1.1.1),  called  pause 
buffer  control,  was  created  to  control  data  flowing  through  the  processing  stream.  This  module 
was  placed  after  the  transient  detection  module.  The  module  allows  an  operator-specified  number 
of  records,  in  this  case  the  size  of  a  data  block  from  the  triggered  buffer,  to  flow  downstream  and 
then  discontinues  reading/writing  data  until  the  downstream  modules  have  completed  processing. 
When  the  downstream  modules  have  completed,  the  pause  buffer  control  module  sends  a 
discontinuity  event.  This  allows  the  downstream  modules  to  cleanup  and  re-initialize  before  it 
makes  the  next  set  of  data  available. 
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This  module  was  implemented  to  support  the  data-buffering  requirement. 


2.1. 1.4  Wave  Output 

The  application  required  that  detections  be  captured  and  placed  into  a  single  channel  wave  file.  A 
SPLIB  module  called  splib  wave  transient  was  created  to  output  the  raw  detection  data  to  a  single 
channel  wave  file.  The  following  file  naming  convention  was  used: 

transient_detection_YYYY_MMDD_HHMMSS_ID_detect_id_X_receiver_Z.wav 

Where: 


•  YYYY  MMDD  HHMMSS  is  the  time  that  processing  was  started. 

•  ID  is  a  serial  number  used  to  uniquely  identify  a  file  grouping.  The  transient  detector 
does  not  make  use  of  this  field  when  generating  output  files. 

•  The  X  following  detect  id  is  an  integer  that  indicates  the  detection  number. 

•  The  Z  following  receiver  is  the  receiver  ID  that  the  detection  occurred  on. 

Note:  Both  X  and  Z  are  zero  indexed  (i.e.  receiver  O). 

An  SPLIB++  module  called  wave  transient  was  created  to  wrap  the  SPLIB  module. 

These  modules  were  implemented  to  support  the  data  buffering  and  recording  requirement. 

2.1. 1.5  Log  Output 

The  application  required  that  detection  information  be  written  into  an  American  Standard  Code  for 
Information  Interchange  (  ASCII)  file  for  logging.  An  SPLIB++  module  called 
logmessagescontrol  was  created  to  read  and  write  log  messages  from  the  transient  detection 
module.  Each  detection  message  received  from  the  transient  detection  module  is  converted  into  a 
STAR  style  log  entry  (See  STAR_analysis_technical_manual.doc)  and  written  to  a  log  file.  If  a 
log  file  already  exists  the  module  will  append  new  detection  messages  to  the  end  of  the  log. 

2.1. 1.6  Combine  Records 

The  application  required  a  single  stream  that  would  indicate  how  far  the  current  data  was  either 
below  or  above  the  detection  threshold.  The  long  term  plan  is  to  feed  this  stream  to  a  graphical  or 
analogue  level  meter.  To  support  this,  an  SPLIB  combine  records  module  was  created.  It  outputs  a 
single  peak  energy  value  relative  to  threshold  across  all  channels.  The  output  data  is  a  single  float 
value  per  record. 

This  module  was  implemented  to  support  the  detection  requirement. 

2. 1. 1. 7  Transient  Detection 

A  transient  detection  SONLIB  module  (sonlib  transient  detection)  was  written  to  control  the 
Sentinel  processing  SONLIB  module,  the  triggered  buffer  SPLIB  module,  and  the  combine 


10 


DRDC  Atlantic  CR  2005-271 


records  SPLIB  module.  This  makes  all  the  outputs  from  these  modules  available  to  higher  layers 
of  code. 

A  SONLIB++  module  called  transient  detection  was  created  to  wrap  the  SONL1B  module.  This 
module  was  implemented  to  support  the  detection  requirement. 

2. 1. 1. 8  Time  Frequency  Normalizer 

It  is  desirable  to  enhance  signals  prior  to  feature  extraction,  which  is  often  done  using  a 
normalizer.  In  this  case,  it  was  desirable  to  enhance  transient  signals  while  not  affecting  longer 
lasting  narrow  bandwidth  signals.  This  type  of  normalization  was  implemented  using  a  time- 
frequency  normalizer  SPLIB  module  (splib_2d_norm).  First,  frequency  based  averaging  was 
conducted  using  a  median  average.  Then  this  average  was  damped  in  time  using  an  exponential 
averager.  Finally  the  overall  average  from  each  scan  was  used  to  normalize  that  scan. 

The  normalizer  was  included  in  the  transient  pre-processing  module  to  support  the  transient  pre¬ 
processing  requirement. 

2. 1.1.9  N  Level  Quantizer 

A  simple  binary  version  of  the  time-frequency  data  is  needed  for  feature  extraction  and  also 
creates  a  simple  black  and  white  GRAM  showing  where  significant  energy  is  present.  An  N  level 
quantizer  SPLIB  module  (splibquantizen)  was  written  that  supports  from  1  to  255  levels  of 
quantization.  For  this  implementation  N  was  set  to  2,  making  it  a  binary  quantizer. 

This  module  was  written  to  support  the  transient  pre-processing  requirement. 

2. 1.1.10  Transient  Pre-processing  SONLIB/SONLIB++ 

A  transient  preprocess  SONLIB  module  was  written  to  control  the  splib_2d_norm  and 
splib  quantize  n  modules.  A  SONLIB++  wrapper  was  created  to  allow  the  transient  pre¬ 
processing  SONLIB  module  to  be  incoiporated  into  the  processing  stream. 

This  module  was  written  to  support  the  transient  pre-processing  requirement. 

2.1.2  Interfaces 

This  section  describes  the  SPPACS  command  line  utility  and  the  QT-based  user  interface  (UI). 

2. 1.2.1  Target  File 

The  processing  stream  is  configured  primarily  through  a  target  file.  The  target  parser  is  used  to 
read  these  files  and  format  the  contents  into  a  form  that  the  rest  of  the  detection  software  can 
understand.  For  an  example  of  a  target  file  with  comments,  please  refer  to  the 
<distribution>/src/stealth/target_files/template.tgt  file  within  the  source  distribution.  The  target 
file  configuration  file  format  and  associated  parsing  software  was  reused  from  the  Sentinel  stealth 
call-up  and  supports  the  module  integration  (configuration  information)  requirement. 
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An  example  target  file  follows: 

#  target  =  targetname 
target=right_whale 

#  spectra  parameters 
nfft=1024  #  FFT  size  to  use 

overlap=0.5  #  percent  overlap  for  FFT  (0.0  to  1.0) 
n_averages=T  #  number  of  FFTs  to  average  for  each  output 
reference_gain=0.7  #  value  at  which  to  switch  between  slow_background 

#  and  fast  background  time  constant.  When 

#  signal  level  *  reference  gain  <  background  level 

#  low_bg_alpha  is  used. 

#  Otherwise  high_bg_alpha  is  used. 

wait_n_records=5  #  number  of  records  (outputs)  to  wait  before  allowing 

#  detections 

#  choose  from  median  or  exponential  signal  estimation  type 
sig_estimator=exponential 

#  band=ID  TYPE  PARM  fstart  fend  low  bg  alpha  high  bg  alpha  sig  alpha  winsz  thr 

#  band  -  fixed  name  to  describe  the  following  line 

#  ID  -  freeform  text  to  describe  the  band  (no  whitespace  allowed) 

#  TYPE  -  S  (signal),  N  (noise)  or  I  (independant  band) 

#  PARM  -  if  signal:  PARM  is  the  frequency  normalized  signal  threshold 

#  -  if  noise:  PARM  is  the  text  identifier  of  the  associated  signal  band 

#  -  if  independant:  PARM  is  not  used,  but  must  be  present  for  parser  to  work 

#  fstart  -  band  start  frequency 

#  fend  -  band  end  frequency 

#  low_bg_alpha  -  low  background  time  constant  (0.0  -  1.0) 

#  high_bg_alpha  -  high  background  estimation  time  constant  (0.0  -  1.0) 

#  sig_alpha  -  fast  background  time  constant  (0.0  -  1.0) 

#  winsz  -  median  normalizer  window  size  [records] 

#  thr  -  time  normalized  threshold  level  at  which  the  Sentinel  will  trigger  for  all  bands,  but 

#  noise  bands  will  never  cause  a  detection  and  signal  bands  must  also  exceed  the 

#  PARM  threshold  to  trigger. 

#  NOTE:  for  alpha  parameters  1.0  means  never  change  the  level  from  the  start 

#  and  values  close  to  1.0  cause  it  to  change  very  slowly.  0.0  means 

#  always  use  the  current  level  and  values  close  to  zero  will  change 

#  the  level  very  quickly. 

#  Triggering  of  a  signal  or  associated  noise  band  will  cause  the  narrowband  test  to 

#  occur.) 

band=right_whale  1  S  4.0  115.0  170.0  0.99  0.9  0.5  10  2.0 
band=noise_rightl_l  N  right_whalel  40.0  100.0  0.99  0.9  0.5  10  3.0 
band=noise_rightl_2  N  right_whalel  180.0  300.0  0.99  0.9  0.5  10  3.0 

band=right_whale2  S  5.0  1300.0  1500.0  0.99  0.9  0.5  10  2.0 
band=noise_right2_l  N  right_whale2  1200.0  1300.0  0.99  0.9  0.5  10  3.0 
band=noise_right2_2  N  right_whale2  1500.0  1600.0  0.99  0.9  0.5  10  3.0 

#  band=shotgun  I NA  50.0  3000.0  0.99  0.9  0.5  10  5.0 

#  band=shotgun  I  NA  1000.0  3000.0  0.99  0.9  0.5  10  3.0 
#band=shotgun  1  NA  500.0  1500.0  0.99  0.9  0.5  10  4.0 

transient_alpha=0.90 
transientwindo  w_size=5  0 
breakpoints=8.0 
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2.1. 2. 2  SPPA  CS  Whale  Detection 


An  SPPACS  utility  was  created  to  allow  the  transient  processing  stream  to  be  executed  through  a 
command  line  interface.  This  supported  testing  and  performance  evaluation  during  the 
development  effort.  In  addition,  it  allows  the  processing  stream  to  be  used  in  scripts  for  batch 
processing.  This  utility  was  created  to  address  the  SPPACS  whale  detection  requirement. 


The  options  available  for  the  utility  are  as  follows: 


sp_transient_processing:  [OPTIONS]  <  INPUT 

-T  [  -target-file  ]  arg 
-d  [  -dat32-header  ] 

-c  [  —  detect-chunk-size  ]  arg  (=10) 

-p  [  -past-records  ]  arg  (=5) 

— multi-time-const 

-i  [  —  background-initial-values  ]  arg 

-f  [  —  log  file  ]  arg  (=transient_detection_log.txt) 
-a  [  —  data-file  ]  arg  (=<stdin>) 

-m  [  —algorithm  ]  arg  (=0) 

—help 

—version 


:  target  definition  file 
:  flag  for  DRDC  header  type. 

:  detection  chunk  size. 

:  number  of  records  saved  before 
detection  event. 

:  initial  values  to  initialize  the 
background  exp_average 
:  transient  message  log  file 
:  the  data  file 

:  algorithm  to  use  for  combine_records. 
:  produce  help  message 
:  produce  version  message 


2.1. 2.3  QTGUI 

GUI  was  created  to  allow  an  operator  to  use  the  transient  processing  stream.  Figure  2  shows  the 
transient  detection  window.  It  consists  of  a  detection  list,  feature  list,  wave  output  button  group 
and  image  view.  The  detection  list  displays  the  detections  found  in  an  output  directory.  The  image 
view  displays  a  black  and  white  image  of  a  detection  event.  The  feature  list  shows  a  listing  of 
detection  messages  associated  with  a  detection  event.  The  wave  control  allows  the  operator  to 
play,  stop  or  view  the  raw  detection  event.  This  application  was  created  to  address  the  event 
analysis  requirement. 
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Transient  Detection 


File  Processing  Help 


Detection  List 


■K  '  »  " 

1459.20  Hz3. 05 .secs  ‘ 

Feature  List 


Serial  *  Date/Time 

Channel 

Band 

Processed  Value  1 

Raw  Value 

Detection  Id  Base  Filename 

1 

58  1999-Jul-29  15:11:39.9940 

39 

4 

2.33772 

25.53526 

36  transient  detection  2005  1008  235406  0  detec 

2 

57  1999-  Jul-29  15:11:39.9160 

39 

4 

2.78291 

23.45145 

36  t ran s  ient_detec ti on_2 005_1 008_2  3  5406_0_detec 

_ J 

Figure  2.  Transient  Detection  Application  showing  right_whale2  Detection 

Input  Settings:  The  input  settings  dialog  is  shown  in  Figure  3.  The  operator  can  change  the  type 
of  input  by  selecting  one  of  the  tabs.  Currently,  only  the  file-based  input  is  supported.  It  allows  the 
operator  to  select  an  input  file  for  processing  and  the  type  of  file.  Currently,  the  system  supports 
DRDC  DAT  and  DAT32  data  files.  Support  for  WAVE  and  Sound  Card  input  can  be  quickly 
added,  as  modules  exist  to  support  these  formats.  To  open  the  input  settings  dialog  select 
Processing->Input  Settings. . .  from  the  menu  bar. 
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Figure  3.  Input  Settings  Dialog 


Processing  Settings:  The  processing  settings  dialog  is  shown  in  Figure  4.  It  allows  the  operator  to 
change  the  detect  chunk  size,  past  records,  target  file  and  output  directory.  Detect  chunk  size 
allows  the  operator  to  adjust  the  number  of  blocks  around  a  detection  event.  Past  records  allows 
the  operator  to  adjust  the  number  of  blocks  that  are  captured  before  the  detection  event.  (NOTE: 
The  block  size  is  the  number  of  records  in  each  Fast  Fourier  Transform  (FFT)  step  size.  This  input 
should  be  converted  to  use  seconds.)  The  target  file  is  a  configuration  file  used  to  define  targets  of 
interest  (see  section  2. 1 .2. 1).  The  output  directory  is  the  directory  that  the  processing  stream  will 
write  all  output  files  to.  The  output  files  include  a  detection  log,  wave  files,  power  spectral  files 
containing  black  and  white  images  of  each  detection  in  a  GRAM  format  and  an  energy  time 
indicator  (ETI)  file  containing  raw  band  energy  in  a  DREA  .pwr  format.  In  this  case  each  bin  is  an 
ETI  band.  To  open  the  dialog  select  Processing->Processing  Settings. . .  from  the  menu  bar. 


Figure  4.  Processing  Settings  Dialog 
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Processing:  The  operator  can  start  processing  by  selecting  Processing->Start.  This  will  execute 
the  SPPACS  utility  sp_transient_processing  using  the  settings  from  the  input  and  processing 
settings  dialogs.  The  output  from  sp_transient_processing  is  written  to  the  output  directory.  The 
operator  can  stop  processing  by  selecting  Processing->Stop. 

Detection  List:  The  detection  list  will  update  with  events  as  they  are  written  to  the  output 
directory.  The  operator  can  view  the  data  for  a  detection  event  by  selecting  the  desired  entry  in  the 
detection  list.  This  will  cause  the  image  view  to  load  the  associated  power  spectral  image  and  the 
feature  list  to  display  the  detection  messages  associated  with  the  detection  event. 

Image  View:  The  image  view  displays  the  power  spectral  output  for  a  detection  event.  The 
operator  can  scroll  horizontally  through  the  frequency  range  and  vertically  through  the  time  range 
of  the  data.  Clicking  on  the  image  will  produce  a  crosshair  cursor  with  frequency  and  time 
annotation. 

Wave  Output:  The  wave  file  containing  the  raw  data  for  the  select  detection  event  can  be  viewed 
by  selecting  View  in  the  Wave  Output  button  group.  This  will  open  a  plot  of  the  wave  file  in  a 
modal  dialog  (as  shown  in  Figure  5).  The  operator  can  zoom  into  a  particular  section  of  the  data 
by  left-clicking  and  dragging  the  cursor  to  highlight  the  desired  area.  Right-clicking  on  the  view 
area  will  cause  the  view  area  to  display  the  entire  data  set. 


Figure  5.  Wave  View  Dialog 
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3.  Data  Processing  and  Analysis 

One  of  the  tasks  in  this  call-up  was  to  process  real  data  through  the  detection  system  to  tune  and 
assess  performance.  The  SA  had  provided  a  number  of  CDs  and  DVDs  with  marine  mammal  calls 
on  them  for  analysis,  but  this  data  was  found  to  have  too  high  of  a  contact  density  to  be  useful. 
Instead,  the  Project  Engineer  (PE)  and  SA  agreed  to  use  30  minutes  by  49  channels  of  Right  whale 
data  collected  using  sonobuoys.  This  data  was  collected  by  Francine  Deshamais  in  the  Bay  of 
Fundy  during  the  summer  of  1999. 

Before  processing,  some  of  the  data  was  observed  in  the  OPD  application  to  assess  the  signature 
of  some  whale  calls.  Two  dominant  whale  calls  were  found.  One  was  a  low  moan  around  150  Hz, 
while  the  other  was  a  higher  pitched  song  around  1400  Hz.  These  were  characterized  as 
rightwhalel  and  right_whale2  respectively  in  the  target  file  shown  in  section  2. 1.2.1.  Shotgun 
events  also  occurred  and  successful  detection  events  were  made,  but  the  false  alarm  rate  was  also 
quite  high  due  to  the  lack  of  contrast  between  the  shotgun  event  and  many  other  transients.  Further 
analysis  may  have  provided  a  better  characterization. 

Once  the  whale  calls  were  characterized  the  target  file  was  used  to  process  two  15-minute  data 
files.  The  data  files  were  created  from  digitized  Analogue  Tape  Recorder  (ATR)  tapes  in  IMPACT 
format.  Each  file  contained  49  channels,  though  many  of  the  channels  contained  only  noise  and 
one  channel  contained  digital  data.  The  valid  data  channels  consisted  of  single  channel  omni¬ 
directional  buoy  data  and  DIFAR  data  in  three  channel  groups.  The  directional  channels  were 
processed  the  same  as  omni-directional  channels  to  get  some  dipole  gain  for  better  detections.  If 
the  processing  was  for  more  than  initial  testing,  proper  beamforming  could  have  been  conducted. 

The  following  summarizes  the  detections  produced: 

•  51  valid  right  whalel  calls 

•  6  valid  right_whale2  calls 

•  6  false  right_whale2  calls  from  radio  conversations 

•  5  false  right_whale2  calls  from  radio  chirps  -  There  was  a  short  burst  signal  sent  on 
processing  channel  11a  number  of  times  that  exactly  matched  the  band  of  the  right  whale2 
call. 

•  5  potentially  false  right_whale2  calls  -  These  were  waterborne  transients  that  didn’t 
have  the  aural  characteristics  of  a  song  and  were  not  shotgun  calls.  They  were  likely 
biologic,  but  the  analyst  couldn’t  confirm  that  they  were  from  right  whales. 

The  prototype  GUI  proved  to  be  very  useful  in  classifying  contact.  After  a  quick  look  through  the 
data,  it  took  an  acoustic  operator,  Joe  Hood,  less  than  a  second  to  recognize  a  valid  call  from  a 
false  alarm  as  he  scrolled  through  the  results.  The  initial  look  involved  examining  the  black  and 
white  gram  and  listening  to  each  type  of  intercept.  As  expected,  aural  classification  was  very 
useful  and  the  gram  provided  for  rapid  image  recognition.  The  gram  also  showed  a  fair  variety  in 
the  whale  call  characteristics  including  duration,  frequency  sweep  and  harmonics  seen.  The  time- 
series  plot  of  data  wasn’t  found  to  be  very  useful  except  that  RF  interference  was  obvious  due  to 
clipping. 
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The  OPD  application  could  have  been  used  to  search  for  missed  contact,  but  this  wasn’t  done  due 
to  effort  limitations  on  the  call-up.  This  will  likely  be  done  as  part  of  another  analysis  call-up 
related  to  marine  mammal  localization. 

There  is  still  room  for  improvement  in  the  automatic  classification  and  GUI  layout  but,  as  a 
prototype,  it  demonstrates  that  good  detections  can  be  made  and  classified  using  a  system  such  as 
this.  The  following  subsection  describes  suggestions  for  improvement. 


3.1  Suggestions  for  Improvement 

As  often  happens  during  call-ups  of  this  nature,  not  all  ideas  are  exhausted  during  the  call-up  and 
new  ideas  are  generated.  This  section  documents  some  of  those  ideas  as  consideration  for  future 
work.  It  is  hoped  that  more  suggestions  are  generated  by  DRDC  and  AD  AC  as  they  use  the 
application.  Suggestions  can  be  logged  on  the  STAR  portal  at  https://star.iotek.ns.ca  or  sent  to  Joe 
Hood  at  MDA  (jhood@mdacorporation.com). 

3.1.1  Reject  /  Accept  Button 

A  reject/accept  button  should  be  added  to  the  GUI.  Once  rejected  or  accepted,  a  detection  could  be 
placed  on  a  different  list  to  show  what  hasn’t  been  analyzed.  Further  to  this,  freeform  text 
annotation  could  be  added  to  the  /logs.  This  would  allow  the  user  to  log  notes  with  the  detections. 

3.1.2  Detection  Summary 

Currently,  the  raw  detection  logs  are  shown  in  the  GUI.  This  should  be  changed  to  show  a 
summary  detection  including  total  detection  time,  detection  min  /  max  level,  etc.  The  detection  log 
should  also  log  the  text  name  of  the  band  being  detected  and  not  the  band  number. 


3.1.3  Feature  Extraction 

Feature  extraction  wasn’t  implemented  due  to  time  constraints.  Though  the  GRAM  display 
enabled  rapid  image  recognition  for  an  operator,  digital  feature  information  will  be  required  for 
more  automated  analysis  and  false  alarm  rejection.  The  first  step  in  this  is  feature  extraction,  as 
planned. 

The  computer-aided  detection/computer-aided  classification  (CAD/CAC)  functionality  used  in  the 
Sonar  Image  Processing  System  (SIPS)  should  be  able  to  provide  a  number  of  reusable 
components  to  aid  in  feature  extraction  and  classification. 

Once  features  are  extracted  they  could  be  automatically  shown  as  each  event  is  analyzed. 

3. 1.4  Zoom 

It  may  be  useful  to  zoom  on  the  gram  display  to  get  a  better  view  of  one  portion  of  the  GRAM. 
Also,  because  the  transient  capture  is  often  very  short,  it  may  be  useful  to  show  the  default  image 
in  a  zoomed  mode. 
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3.1.5Chunk  Size  Units 


The  UI  should  be  changed  to  let  the  user  define  the  chunk  size  in  seconds  and  not  the  number  of 
FFT  blocks. 

3.1.6  Live  Data 

More  variations  on  the  data  in  module  should  be  added  as  options.  This  should  include  soundcard 
analogue-to-digital  (A/D)  output,  WAVE  files  and  other  data  capture  hardware.  This  would  enable 
a  live  trial  at  sea,  which  should  prove  very  useful  in  generating  further  feedback  on  the  design  and 
algorithms. 

3.1.7  Remote  Sensing  /  Operational  Use 

The  application  was  built  so  that  it  could  be  installed  in  systems  like  the  Stealth  buoy.  This  variant 
should  also  be  trialed  for  remote  monitoring  of  an  area.  The  library  modules  could  also  be 
integrated  into  systems  like  the  Integrated  Multistatic  Passive/Active  Concept  Testbed  (IMPACT) 
for  use  during  trials. 
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4.  Maintain  Configuration  Management 


STAR  and  SPPACS  are  maintained  using  subversion.  The  most  recent  release  version  is 
maintained  and  bug  fixes  are  applied  to  that  version,  as  required,  ensuring  that  a  stable  release  is 
always  available.  Simultaneously,  software  enhancements  are  applied  to  the  development  version 
and  bug  fixes  are  merged  with  this  version.  Once  a  call-up  nears  completion,  or  a  release  of  the 
software  is  otherwise  required,  a  new  release  version  is  branched  off  of  the  development  stream 
for  final  integration,  release  testing  and  delivery. 

STAR  (includes  SPPACS)  release  4.8.0  (tag  star_release_4_8_0)  was  created  under  this  contract 
to  serve  as  a  baseline  while  the  analysis  work  was  being  conducted.  This  allows  development  to 
continue  on  the  trunk  of  the  distribution.  The  trunk  usually  contains  newly  implemented  software, 
which  may  not  be  stable  enough  to  allow  for  operational  use. 
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5.  Track  Software  Issues 


Defect  tracking  systems  allow  users  to  effectively  keep  track  of  outstanding  bugs  in  their  product. 
STAR  and  SPPACS  issue  tracking  is  performed  using  a  web  accessible  tool  called  Bugzilla.  This 
tool  can  be  accessed  using  a  secure  web  interface  at  https://star.iotek.ns.ca.  Once  the  appropriate 
security  procedures,  detailed  on  the  web  page,  have  been  followed,  users  and  developers  can  use 
this  site  to  add,  view  or  modify  issues  related  to  the  software  packages. 

A  breakdown  of  the  current  issues  for  the  STAR  and  SPPACS  distributions  are  shown  in  Table  3. 
The  total  number  of  unresolved  issues  is  shown  in  the  NEW/ASSIGNED/  REOPENED  column. 
The  total  number  of  opened  issues  is  broken  into  two  classes  of  severity.  Issues  classified  as 
BLOCKER/CRITICAL/MAJOR  are  issues  that  should  be  addressed  in  the  short  term.  Blockers 
are  always  addressed  immediately  to  ensure  that  the  user  community  can  continue  with  their  work. 
Issues  classified  as  NORMAL/MINOR/TRIVIAL  are  issues  that  can  be  dealt  with  in  the  long 
term. 

None  of  the  issues  described  below  affect  this  call-up. 


Table  3.  Distribution  Issue  Summary  (01/1 1/2005) 


PRODUCT 

NEW/ASSIGNED/ 

BLOCKER/CRITICAL/ 

NORMAL/MINOR/ 

REOPENED  (TOTAL) 

MAJOR 

TRIVIAL 

SPPACS 

39 

1 

38 

STAR 

60 

4 

56 

The  following  gives  a  more  detailed  description  of  the  SPPACS  BLOCKER/  CRITICAL/MAJOR 
column: 

•  Issue  #  284  (major)  fails  DAT32  byteswap  case.  The  utility  is  attempting  to  read  the  extra 
gains  using  the  original  header,  which  may  be  in  a  different  byte-order  than  the  platform. 

The  following  list  gives  a  more  detailed  description  of  the  STAR  BLOCKER/ 

CRITICAL/MAJOR  column: 

•  Issue  #193  (critical)  tacplot  does  not  cleanup  before  exiting.  The  workaround  for  this  issue 
is  to  run  heap  gc  after  the  analysis  window  has  closed. 

•  Issue  #107  (major)  problems  capturing  close  button.  A  solution  exists  for  this,  but  has  only 
been  incorporated  into  the  tactical  plot.  The  exit  button  provides  application  termination 
capability. 

•  Issue  #  295  (major)  capture  screen  doesn’t  work  correctly.  The  Capture  Screen  button  does 
a  screen  capture  on  the  analysis  window  and  not  the  tactical  plot.  Taking  a  screen  capture 
immediately  after  opening  the  window  can  solve  this  problem.  A  fix  has  been  implemented 
and  will  be  released  with  the  next  version. 
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•  Issue  #  329  (major)  overlays  need  to  be  optimized.  The  tactical  plot  is  too  slow  (on  Bender). 
To  load  on  Bender  (dual  P4-  1  GHz),  it  takes  approximately  20  seconds  the  first  time  and 
15  to  20  seconds  thereafter.  If  you  don’t  require  AOP  overlays  on  the  tactical  plot,  disable 
them  on  the  tactical  plot  settings  dialog. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


A/D 

Analogue-to-Digital 

ADAC 

Acoustic  Data  Analysis  Center 

API 

Application  Program  Interface 

ASCII 

American  Standard  Code  for  Information  Interchange 

ATR 

Analogue  Tape  Recorder 

CAD/CAC 

Computer-Aided  Detection/Computer-Aided  Classification 

CD 

Compact  Disc 

CVS 

Concurrent  Versioning  System 

DND 

Department  of  National  Defence 

DRDC 

Defence  Research  &  Development  Canada 

DREA 

Defence  Research  Establishment  Atlantic 

DRP 

Document  Review  Panel 

DVD 

Digital  Versatile  Disc 

EA 

Enterprise  Architect 

ETI 

Energy  Time  Indicator 

eft 

Fast  Fourier  Transform 

FFTW 

Fastest  Fourier  Transform  in  the  West 

GUI 

Graphical  User  Interface 

HTML 

Hypertext  Markup  Language 

ID 

Identification 
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IDL 

Interactive  Data  Language 

IMPACT 

Integrated  Multistatic  Passive/Active  Concept  Testbed 

MDA 

MacDonald  Dettwiler  and  Associates  Ltd. 

OPD 

Omni  Passive  Display 

PC 

Personal  Computer 

PE 

Project  Engineer 
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